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. Smart Card with Business Partner Scheme or Travel Applications 

The present invention relates generally to the use of integrated circuit cards, or 
"smartcards'\ for commercial transactions and» more particularly, to methods and 
apparatus for conveniently storing, retrieving, and updating data related to a 
cardholder's travel infonnation in the context of a distributed transaction system. 

Despite advances in infomiation technology axKi process streamlining with 
respect to travel arrangements, the modem traveller is often subjected to unnecessary 
delays, petty inconveniences, and oppressive paperwork. These travel burdens are most 
evident in the airline, hotel, and rental car industries, where arranging and paying for 
services and accommodations can involve significant time delays due to 
misconununication, poor record-kieeping, and a host of other administrative 
inefficiencies. 

Smartcard technology, as described below, has had limited success in addressing 
some of these problen^. The term ''smartcard** refers generally to wallet-sized or 
smaller cards incorporating a microprocessor or microcontroller to store and manage 
data within the card. More complex than magnetic-stripe and stored*value cards, 
smartcards are characterized by sophisticated memory management and security 
features. A typical smartcard includes a microcontroller embedded within the card 
plastic which is electrically connected to an array of external contacts provided on the 
card exterior. A smartcard microcontroller generally includes an electrically-erasable 
and progranunable read only memory (EEPROM) for storing user data, random access 
memory (RAM) for scratch storage, and read only memory (ROM) for storing the card 
operating system. Relatively simple microcontrollers are adequate to control these 
functions. Thus, it is not unusual for smartcards to utilize 8-bit, S MHZ 
microcontrollers with about 8K of EEPROM memory (for example, the Motorola 6805 
or Intel 8051 microcontrollers). 

A number of standards have been developed to address general aspects of 
integrated circuit cards, e.g. ISO 7816-1, Part 1: Physical characteristics (1987); ISO 



mf*-2. Pan 2: Dimensions ond location of the coniacis (1988); JSO 7816-3, Pari 3: 
Electronic 5ignah and tronsmmionproiocois{ym.Am±\ 1992. Aind.2 1994); 750 
7816-4. Port 4: Imer-industry commands for interchange ISO 7816-5. Part 5: 

fJumberingsystemandregistrationprocedureforopplicotionidentifiers(\99<Am^^ 

5 1 995); ISO/lEC DJS 781 6-6. Inter-indusiry data elements ( 1 995); ISO/lEC WD 7816-7. 
Pan 7: Enhanced imer-industry commands (1995); and ISO/lEC WD 7816-8. Part 8: 
Inier-industry security architecture (1995). TTiese standards are hereby incorporated by 
reference. Funhermbre. general infoimation regarding magnetic stripe cards and chip 
cards can be found in a number of standard texts, eg. Zoreda & Oton. Smart CaRDS 

10 (1994). and Rankl & Effing. Smart Card H andbook (1997), the cements of which are 

hereby incorporated by reference. 

Variousattcmpts have been made loalleviate travel-related inconveniences through 

,he use of smartcard technology. In 1995. for example, the U.S. airline industry led an 
effort to reduce ticket distribution costs by developing standards for "ticketless travel." 

,5 Soon thereafter, a joint conference of lATA and ATA adopted a set of specificaUons 
entitled Specifications for Airline InduMry Integrated Circuit Cords (hereinafter, "1 ATA 
standard"). Similarly, in the field of financial payment systems, a standard has been 
developed entitled EMV Version 2.0. Integrated Circuit Card Specifications for Payment 
Systems. Paris 1-3 (1995). Both of these specifications are hereby incorporated by 

20 reference. 

Noixvithstanding widespread promulgation of these sundards. smartcard efforts 
,cnd to remain fragmented; and the resultam benefit lo consumers - particularly 
consumers who travel has been quite minimal. One recent study estimates that 
approximately nine million smartcards were issued in the transporution and travel 
industry in 1 996. yet. for the most part, these cards remain incompaiible; thai is. due to 
differing file stnictures and/or communication protocols employed, card data typically 
can not easily be shared across applications or between industry participants. 

Systems and methods are therefore needed in order to overcome these and other 
shortcomings in the prior art. 
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The prcseni jnvcniion pro\'idcs mcihods and apparatus for a smartcard system 
v/hidh securely and conveniently iniegraies imponant travel-related applications, theicby 
overcoming the Jimitations of the prior an. In accordance with one aspect of the present 
invention, a smartcard system comprises a cardholder identification application and 
various additional applications useful in particular travel contexts; for example, airiine, 
hoteK rental car, and paymeni-related applications. In accordance with another aspect of 
the present invention, a smartcard system further comprises space and security features 
within specific applications which provide partnering organizations the ability to 
construct custom and secure file structures. 

The present invention will hereinafter be described in conjunction with the 
appended drawing figures, wherein like numerals denote like elements, and: 
Figure 1 illustrates an exemplary smartcard apparatus; 

Figure 2 is a schematic diagram of an exemplary smartcard integrated circuit, 
showing various functional blocks; 

Figure 3 is an exampiaiy diagram of files and directories arranged in a typical tree 
structure; 

Figure 4 sets forth an exemplary database structure in accordance with a preferred 
embodiment of the present invention; 

Figures sets forth a preferred cardholder ID data structure in accordance v^th the 
present invention; 

Figure 6 sets forth a preferred payment system data structure in accordance v^th 
the present invention; 

Figure 7 sets forth a preferred airline data structure in accordance with the present 
invention; 

Figure 8 sets forth a preferred rental car data structure in accordance with the 
present invention; 

Figure 9 sets forth a preferred hoiej system data structure in accordance with the 
present invention; and 



Figure 10 illiisiraies an exemplary disiribmcd iransaction system useful in 
practicing the present invention. 



5 Referring now to Figures 1 and 2, an exemplary smancard system suitable for 

practicing the present invemion will now be described. A smartcard 100 generally 
comprises a card body 1 02 having a communication region 1 04 for providing contact or 
non-contact communication between an external device (e.g., a card reader) and an 
integrated circuit 1 10 encapsulated vwthin card body 102. Communication region 104 

10 preferably comprises six conductive pads 1 06 whose placement and size conform to 
1S07816t2. More particularly, a communication region 104 in conformance with ISO- 
78 1 6-2 preferably comprises VCC contact 1 06(a) (power supply), RST contact 1 06(b) 
(reset), CLK contact 1 06(c) (external clock), GND Contact 106(d) (ground), VPP contaa 
1 06(c) (programming voltage), and 1/0 contact 1 06(f) (data line). 

15 VCC 1 06(a) suitably provides power to IC 11 0 (typically 5.0 V +/- 1 0%). CLK 

106(c) is suitably used to provide an external clock source which aicts as a data 
transmission reference. R$T 1 06(b) is suitably used to transmit a reset signal to IC 1 1 0 
during the booting sequence. VPP contact 106(c) may be used for programming of 
EEPROM 2 12 in IC 1 1 0. As is known in the art. however, this'contact is generally not 

20 used since modem ICs typically incorporate a charge pump suitable for EEPROM 
programming v**ich takes its power from the supply voltage (VCC 1 06(a)). 1/0 1 06(f) 
suitably provides a line for serial data communication with an external device, and GND 
1 06(d) is suitably used to provide a ground reference. Encapsulated integrated circuit 
1 10 is configured to communicate electrically with contacts 106 via any number of 

25 known packaging techniques, including, for example, therroosonically-bonded gold 
vwres, tape automated bonding (TAB), and the like. 

While an exemplary smartcard is discussed above in the context of a plurality of 
external contacts, it will be appreciated that conwctless cards may also be utilized to 
practice this invention. That is, non-contact communication methods may be employed 

30 using such techniques as capacitive coupling, inductive coupling, and the like. As is 
known in the art, capacitive coupling involves incorporating capacitive plates into the 
card body such that data transfer with a card reader is pn)vided through symmetric p^ 



of coupled surfaces, wherein cnpacitancx: vnlues are tj'picaily I O^SO picofarads, and the 
wx^rking range is typically less than one millimeter: Inductive coupling employs coupling 
elcriients, or conductive loops, disposed in a weakly*coupled transformer configuration 
employing phase, frequency, or nmpliuide modulation. In this regard, it will be 
5 ^ appreciated that the location of communication region 1 04 disposed on or within card 
1 00 may vary depending on card configuration. For additional information regarding 
non-contact techniques, see, for example, contactless card standards ISO/IEC 10536 and 
ISO/I EC 1 4443, which are hereby incorporated by reference. 

Smartcard body 102 is preferably manufactured from a sufficiently rigid material 
1 0 which is resistant to various environmental factors, e.g., physical deterioration, thermal 
extremes, and BSD (electrostatic discharge). Materials suitable in the context of the 
present invention include, for example, PVC (polyvinyl chloride), ABS (acrylonitrile- 
butadiene-styrol), PET (polyethylene terepbthalate), or the like. In a prefeired 
embodiment, chip card 100 conforms to the mechanical requirements set forth in ISO 
15 7810, 7813, and 7816. Body 102 may comprise a variety of shapes, for example, the 
rectangular ID-1, ID-00, or lD-000 dimensions set forth in ISO-7810. In a preferred 
embodiment, body ] 02 is roughly the size and shape of a common credit card and 
substantially conforms to the ID- 1 specification. 

Referring now to Figure 2, IC 110 preferably comprises regions for Random 
20 Access Memory (RAM) 216, Read-Only Memory (ROM) 214, Central Processing Unit 
(CPU) 202. data bus 210, Inpui/Ouiput (1/0) 208 and Electrically-Erasable and 
Programmable Read Only Memory (EEPROM) 212. 

RAM 216 comprises volatile memory which is used by the card primarily for 
scratch memory, e.g., to store intermediate calculation results and data encryption 
25 processes. RAM 2 1 6 preferably comprises at least 256 bytes. 

EEPROM 212 provides a non*volatile memory region ^ich is erasable and 
rewritable electrically, and which is used to store, imer alia^ user data, system data and 
application files. In the context of the present invention, EEPROM 212 is suitably used 
to store a plurality of files related to cardholder travel information (discussed in greater 
30 detail below in conjuncuon with Figure 3). EEPROM 212 preferably comprises at least 
8K bytes. 
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In a preferred embodiment CPU 202 implementsthe insmiclion set stored in ROM 
202. handles memory managemem (i.e., RAM 216 and EEPROM 212). and coordinates 
inpui/output aciiviiics (i.e., 1/0 208). 

ROM 214 preferably contains, or is "masked" with, the smart card operating 
system (SCOS). That is, the SGOS is preferably implemented as hard-wired logic in 
ROM 214 using standard mask design and semiconductor processing methods well 
known in the art (e.g. photolithography, diflusion. oxidation, ion implantation, etc.). 
Accoidingly. ROM 2 14 cannot generally be altered after fabrication. The puiposc of such 
an implementation is to take advantage of the fast access times provided by masked 
ROMs. ROM 2 1 4 suitably comprises about 4K.20K bytes of memoiy. preferably at least 
16K bytes. In this regard, it will be appreciated that alternate memory devices may be 
used in place of ROM 214. Indeed, as semiconductor technology progresses, it may be 
advantageous to employ more compact fom« of memory, for example. flash-EEPROMs. 

The SCOS comrols information flow to and from the card, and more particularly 
facilitates storage and retrieval of data stored within EEPROM 212. As with any 
operating system, the SCOS operates according to a well-defined command set. In this 
regard, a variety of known smart card operating systems are suitable for the purpose of 
U,is inLtion, for example. IBM's Multi-Function Card (MFC) Operating System 3.51, 
the specification of which is hereby incorporated by reference. While the IBM MFC 
operating system employs the starKJard tree stn,cture of files and directories substantially 
in accordance with 1S07816.4 (as detailed below), it will be appreciated by those skilled 
j„ ,he art that other operating system models would be equally suitable for 
implementation of the presem invemion. Moreover, it may be advantageous to allow 
ccnain aspects of operating system fimctionality to exist outside the card. Le., in the fom. 
of blocks of executable code which can be downloaded and executed by the smartcard 
during a transaction (for example. Java applets. ActiveX olgects. and the like). 

Given the general charecteristics of smartcard 100 as outlined above, it ^11 be 
apparent that a wide range of microconuollers and contact-based smartcanl products 
.known in the an may be used to implement various embodiments of the present 
invention. Suitable smartcaids include, for example, the model ST16SF48 card. 
rt^matd by SGS-Thomson Microelectroiucs. which incoipomtesa Motorola 6805 
microcontroller with 16K ROM. 8K EEPROM. and 384 bytes of RAM. It vnW be 



appreciated, however, ihai particular embodiments of the present invention might require 
more advanced microcontrollers with greater EEPROM capacity (i.e., in the range of 
about 1 2- 1 6K). Such systems arc well known in the art. 

Having thus described an exemplary smartcaid 100 and IC ] 1 0, an overview of a 
smancard file struaiire in accordance with the present invention will now be described. 
Referring now to Figure 4« file structure 400 is preferably used lo store information 
related to card-holder preferences and various data useiul for securing and paying for air 
travel, rental cars, hotel reservations and the like. More particularly, file structure 400 
preferably comprises cardholder ID application 406, payment system application 408, 
airline application 410, hotel system application 412, rental car application 414, and 
cardholder verification data 404. It will be appreciated by those skilled in the art that the 
term ''application" in this context refers to self-contained regions of data all directed at 
a particular function (e.g., airline, hotel, etc.) rather than a block of executable software 
code, although the use of executable modules as part of any particular application falls 
within the scope of the present invention. 

Cardholder verification data 404 preferably houses data useful in verifying 
cardholder identity during a transaction. In a preferred embodiment, cardholder 
verification data 404 comprises two eight-byte cardholder verification numbers (i.e., PIN 
numbers) referred to as CHVl and CHV2. 

Cardholder ID application 406 suitably comprises variotis files related to personal 
information of the cardholder (e.g., name, addresses, payment cards, driver's license, 
personal preferences and the like). Cardholder ID application 406 is described in greater 
detail below in conjimction with Figure 5. 

Payment system application 408 suitably comprises information usefbl in effecting 
commercial transactions, e.g., account number and expiration date information 
traditionally stored on a magnetic-stripe credit card. Alternatively, Payment system 
application 408 comprises a full EMV-compliant application suitable for a wide range 
of financial transactions. Payment system application 408 is described further'below in 
conjunction with Figure 6. 

Airiine application 4 1 0 suitably comprises data helpful in streamlining conunercial 
airline travel; for example, relevant personal preferences, electronic tickets, and frequent 



flier infonnaiion. Airline application 410 is discussed in greater detail below in 

conjunction with Figure 7. 

Hold applicaiion 412 suitably comprises information useful for securing and 
paying for hotel reservations, including an array of information and preferences 
5 associated with a list of preferred hotels as ^ve!l space for electronic keys. Hotel 
application 412 is discussed in greater detail below in conjunction with Figure 9. 

Rental car application 414 suitably comprises dau useful in expediting the process 
of car renul and return, including, for example, car preference and frequent rental 
information. Rental car application 4 1 4 is described in furtha detail below in conjunction 

10 with Figure 8. 

In each of the above mentioned applications, sophisticated access and encryption 

schemes are preferably utilized in order to allow multiple parties to make use of certain 

file structures while preventing unauthorized entry into others. More specifically. 

paruiering organizations (e.g.. hotel chains, airlines, and rental car agencies) may create 
15 their ovm tailor-made file structures (i.e., "partner file structures") within card 100. 

Details of the various security measures employed are described in further detail below 

in conjunciion with Tabic 40. 

Referring now to Figure JO. smancard 100 is suitably used in the context of a 
distributed transaction system. Briefly, cardhdlder's may employ smartcard 100 at 
20 various access poinu 15 which are connected via network 19 to an issuer lO and at least 
one partnering organization 12. Issuer 10 suitably comprises various hardware and 
softvwire components suitable for client host communications as well as a database 
. system 1.1. In this context, the teim issuer" refers to the organization that actually issues 
Uie smartcard and retains some high-level access to certain areas of file stracture 400 

25 (detailed below). 

Partnering organizations 12(aX 1 2(b). and so on. fcomprisc the various hotel chains, 
rental-car agencies, airlines, and the like, who have access to appropriate data regions 
within smartcard J 00. Each partnering organizaUon 12 suitably comprises a aatabasc 13 
and appropriate hardware and softxvare components necessary for compleUng a 
uansaction over network 19. Networic 19 may comprise one or more communication 
modes. e.g. the public switched telephone networic (PSTN), the Internet, digital and 
analog wireless networks, and the like. 

8 
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Eacli access poini 1 5 suimbly comprises an appropriaie card reader for interfacing 
wiih smart card 100 ns \velJ as hard\varc and software suitable for interfacing with a 
cardholder and performing a transaction over network 1 9. Access points 1 S are pieferably 
located in areas providing convenient access for traveling cardholders or cardholder's 
S preparing travel arrangements. Such access points 15 may be located, for example, in 
airline ticketing and gate areas, rental cur facilities, hotel lobbies, travel agencies, and 
stand-alone kiosks in malls. In addition, businesses might see fit to host an access point 
15 to streamline their employees' business travel. Furthermore, an individual cardholder 
might configure his or her personal computer to act as an access point using appropriate 
10 software and peripheral h;ird ware. 

In a preferred embodiment of the present invention, data files and directories are 
stored in n "tree" stnicturc as illusrmrcd in Figure 3. That is. the smancard file structure 
resembles the well known MS-DOS (Microsoft Disk Operating System) file structure 
wherein files are logically organized within a hierarchy of directories. Specifically, three 
15 types of files arc defined in ISO 7816-4: dedicated files (DF)t elementary files (EF). and 
a master file (MF)- The master file is analogous to the MS-DOS "root" directory, and 
contains all other files and directories. Dedicated files are actually directories or "folders" 
for holding other DFs or EFs. Thus, MF 302 may contain an arbitrary number of DFs 
306, and these DFs (e.g., DF 306(a)) may or may not contain other DFs (e.g., DF 308). 
20 Elementary files are used to store user data, and nrjay exist within a dedicated file (e.g., 
EF 3 1 0 within DF 306(a)), or within the master file (e.g.. EF 304 within MF 302). Higher 
level DFs (i.e., DFs which house particular applications) are often referred to as 
application dedicated files (ADFs). 

The MF and each of the DFs and EFs are assigned a unique two-byte file identifier 
25 (FID). By convention, the MF is traditionally assigned an FID of •3F00' hex. Selection 
of an EF or DF by the operating system may then be paformed by tracing its entire path 
starting at the MF. Thus, if the MF containsa DF with a FID 'AlOG', and this DF in turn 
contains an EF with a FID 'A 101', then this EF could be referenced absolutely by 
successive selection of FIDs 3F00, A 1 00, and A 1 01 . It will be appreciated that the FID 
30 is essentially a file name used by the operating system to select direaories aiid files; it 
is not intended to indicate a physical address within EEPROM 212. As will be 
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appreciated by .hose skilled in .he art. low-level EEPROM addressing is preferably 
handled by the SCOS in conjiinciion wiih CPU 202. 

Each file preferably lias an as.sociaied file header containing various indicia of the 
particular EF, DP, or MF. More particularly, the file header associated with a particular 
nie preferably includes the file identifier (FID), file size, access conditions, and file 
sinicurc. In this regard, smartcard 100 suitably employs one of four file structures: 
transparenu linear fixed, linear variable, or cyclic. For the sake completeness, the nature 
of these file structures v^ill be brielly reviexved. 

A transparent file strocturc consists of a siring of bytes accessed by specifying an 
offset and byte co.mt. For example, wi.h reference .0 Table I below, given a /,-byte 
string of data, bytes 7 through 1 0 xvould be accessed using an offset of six and a length 
of four. 



byw* 

I 2 3 4 



5 6 7 8 9 



10 n .2 13 14 




Table 1 : Transparent file stniaure 



A linear fixed file structure comprises a plurality of records of equal length (e.g., 
a list of phone numbers), wherein access to an individual record is achieved through 
reference.0 a record number. In addition, it is possible .0 refer 10 the 'next' or 'previous' 
record relative to the 'current' record (i.e., the most recently accessed record). In contrasi. 
a linear variable file structure comprises records of arbitrary but known length, and is 
therefore typically more compact than linear fixed data structures. 

A cyclic file structure is a type of linear fixed file wherein a pointer is used to point 
to the last data set written to. After the last dau record is written to, the pointer returns 
to the first record. TTuit is. . cyclic file comprises a series of records arranged in a Ting' . 

A data structure particulariy important with regard to storing lecords as well as 
secure messaging in smartcani applications is the BER tag-length-valuc or 'TLV" 
s,n.ctureinaccordancewithlSO/lEC8825.herebyincoTporatedlv maTLV 

10 



objccu infomiarion regarding ihc lypc and length of the information is included along 
with the actual data. Thus, a TLV object comprises a tag which identifies tlie type of daia 
(as called oul by ihe appropriate specification), a length field which indicates the length 
in bytes of the daia to follow, and a value field, which comprises the primary data. For 
example, the TLV object illustrated in Tabic 2 below encodes the text "phoenix*', which 
has a length of 7 bytes, and concsponds to a the "city" tag oi'ZC hex (a hypothetical tag 
designation). 





Tag 


Length 


Value 


10 




•or 


P 


h 


0 • 


• 1 


" 1 


i 


1 » 



TABLE 2: Exemplary primitive TLV object 



It will be appreciated that the meaning of the various tag values must be known to 
the system a priori That Is, in order for the tag field to be useful, the simartcard and any 
external systems communicating wth the smancard must conform lo the same tag 

1 5 specification. In this regard, ISO/lEC 78 1 6-6 defines a series of tags uscfiil in the context 
of the present invention, as does the JBM MFC 3^ specification. ISO/lEC 8825 sets 
forth the basic encoding rules for a TLV system and defines a "template" data object 
which can be used as a container for multiple TLV objects. That is, it is often 
advantageous to encapsulate priiniiive TLV objects within a larger template vs^hich is 

20 itselfa TLV object. 

Referring now to Figure 4, a preferred smancard data sunjcture in accordance with 
the present invention will now be described in detail. Data structure 400 preferably 
comprises a MF 402 and five DFs: Cardholder ID application 406, Payment system 
application 408, Airline application 410, Hotel application 412» and Rental car 

2S application 414. 

In the detailed description to follow, various acronyms and abbreviations vail be 
used to refer to particular data types, formats, and the like. A key to these acronyms and 
abbreviations is presented in Table 3 below. 

AN Alphanumeric 
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IS 



20 



25 
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N Numeric 

B Boolean 

C Conveniion 

M Matrix 

D Data 

AR Bits array 

Bn>) Binary 

RJ Right-justified 

LI Left-justified 

BCD Binary coded decimal 

TABLE 3: Key to acronyms 
In the discussion that follows, the various featuits of a preferred data struaure 
are in some cases described using particular file structure types (i.e., transparent, 
fixed, etc.). Those skilled in the art will realize, however, that any of the common 
smar^card file strucwie types are typically suitable for implemcniing any particular 
data structure. For example, when a file structure is described as including "a plurality 
of records." it will be understood that such a structure may be designed, for example, 
using a lisi of records assembled in a linear fixed file wherein each record is itself a 
transparent file (and offset values correspond to the various fields). Alternatively, 
such a siruciure may be designed using TLV strings assembled in a linear fixed file or 
>vithin a larger template TLV. This is the case notwithstanding the fact that particular 
tag values - which are for the most part arijitrary - arc not explicitly listed in the 
tables that follow. 

Cardholder ID Application 

Referring now to Figure 5, Cardholder ID application 406 is used to store various 
irfomiation lelated to the cardholder. Portions of this information are freely available to 
UK partnering organizations, thereby preventing the storage of redundant information. 

More particularly, cardholder ID application 406 preferably comprises directory 
EF 532. holderJD DF 502 and miscellaneous DF 530. HolderJD DF 502 preferably 
comprios ID EF 504. home EF 506. business EF 508. preferences EF 514. passport EF 
516 authentication EF 520. biometric EF 522. and driver EF 518. Miscdtancous EF 530 
prefcnibly comprises payment cart EF 5 1 0. sequence EF 5 12. issuance EF Sn 
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programs EF 528, and card number EF 526. These files and iheir respective funciions arc 
discussed in deiail below. 

Directoiy EF 532 provides a list of application identifiers and labels for the various 
high-level DF's existing under cardholder ID application 406. That is, this lile serves the 
function of a high-level direcion' listing which specifies the location (i.e., PID) and 
application label for each DF - in this case, holderJD DF 502 and miscellaneous DP 
530. In a panicularly preferred embodimcnl, directory EF 532 is structured in accordance 
with £M V 3.0 as shown in Table 4 below. Preferably, each major application (e.g., hotel, 
airline, etc.) has an associated directory file with a substantially same file structure. 



Record descrtpcioH 


Evlcrnal rormal 


lnicrii:il roriii;iC(bylcs) 




Size 


Type 


Size 


Type 


Application ID for ho!dcr_JD DF 


16 


AN 


16 


ASCII 


Application label 


16 


AN 


16 


ASCII 


Application ID for miscellaneous DF 


16 


AN 


16 


ASCII 


1 Application label 


16 


AN 


16 


ASCII 



Table 4: Exemplary cardholder ID directory EP 



ID EF 5iM preferably includes personal information related to the cardholder, e.g., 
name, date of binh, emergency contact, general preferences, and the like. In a particularly 
preferred embodimeni, member EF 504 comprises the fields set forth in Tabic 5 below. 
Italicized field names indicate a subcaiegory within a particular field. 



Record dcscriptioii 


External fornial 


Internal fonnai(bytcs) 




Size 


Type 


Size 


Type 


Last Name 


30 


AN 


30 


ASCII 


Pint Name 


20 


AN 


20 


ASCII 


Middle Name 


S 


AN 


8 


ASCII 


Honorary Tiilc 


8 


AN 


8 


ASCII - 


NaroeSttfToc 


4 


AN 


4 


Asai 


Date of Birth 


S 


D 


4 


BCD 
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Social Securiiy Number 


1 A 

Iv 


AN! 


10 


ASCII 


Emergency Contaci 










lost Name 


xV 




20 


ASCII 


First Name 


10 


An 


in 


ASCII 




/ 


c 


/ 


BIN 


Phone 


20 


N 


10 


BCD 


Gcndtf > 


1 


AN 


1 


ASCII 


Special Personal Requirementt 


12 


AN 


12 


M 


Ufif uage Preference (ISO 639) 


2 


C 


2 


ASCII 



10 



Table 5: Exemplary ID EF data siruclurc 



In the above table, and ihe tables to follow, both internal and external data 
formats are listed. As the conservation of EEPROM space is of paramount 
importance, the "internal" format of data (i.e.. within EEPROM 212) may be 
different from the "extemal" format of the data (i.e.. as read by the card reader at 
15 an access point 15). Thus, for example, a date field might consist of a four-byte 
BCD record within the card, but upon reading and processing by the terminal, this 
data might be converted to an eight-byte decimal value for more convenient 

processing- 
Home EF 506 preferably includes data related to one or more of the 
20 cardholder's home addresses. In a particularly preferred embodiment, home EF 506 
comprising the fields set forth in Table 6 below. Tlie personal travel charge account 
pointer is preferably used to designate a preferred payment card, and consists of a 
number conesponding to one of the payment card records within payment card EF 
510 (detailed below). 



Record dcscripliOB 


External formal 


Inlcrnal for 


mat(bytcs) 




Size 


Type 


Sitt 


Type 


Home Address 1 


40 


AN 


40 


ASCII- 


Home Address 2 


40 


AN 


40 


ASai 


Home Address CHy . 


25 


AN 


25 


ASCII 



25 
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Home Address Suite 


5 


AN 


5 


ASCII 


Home Couniry (ISO 3166) 


2 


AN 


2 


ASCII 


Home Address Zip Code 


10 


AN 


10 


ASCII 


HAHie Address Teleohone 


20 


N 


10 


BCD 


Home Address FAX 


20 


N 


10 


BCD 


Home E-mail address 


40 


AN 


40 


ASCII 


Personal travel charge accoum number 
pointer 


2 


N 


1 


BCD 



Table 6: Excmplaiy home EF file structure 



Business EF 508 preferably includes various data related to ihc cardholder's 
business (i.e., addresses, phone numbers, and the like). In a particularly preferred 
embodiment, business EF 508 comprising the fields set forth in Table 7 below. In 
this regard, the credit card pointer field is preferably used to point to a payment card 
record within payment card EF 510 (detailed below). The cost center, dept., 
division, and employee ID fields are employer-specific, and may or may not apply 
in a given case. 



Record dcscripf ion 


ExfcrnBl formal 


Inicrnal rormal(bytcs) 




Size 


Type 


Size 


Type 


Business Address 1 


40 


AN 


40 


ACSil 


Business Address 2 


40 


AN 


40 


ASCII 


Business Address City 


25 


AN 


25 


ASCII 


Business Address Sute 


5 


AN 


5 


ASCII 


Business Country (ISO 3 1 66) 


2 


AN 


2 


ASCII 


Busiiiess Address Zip Code 


10 


AN 


10 


ASCII 


Business Telephone No. 


20 


N 


10 


BCD 


Business Address Fax 


20 


N 


10 


BCD 


Business E-mail Address 


40 


AN 


40 


ASCII 


Professional Title 


10 


AN 


10 


ASCII 


Employee ID 


10 


AN 


10 


ASCII 



IS 



Oivision 


20 


AN 


20 


ASCII 




20 


AN 


20 


ASCII 




12 


AN 


12 


ASCII 


Professional travel account number . 
pointer 


2 


N 


2 


BCD 


Professional license <laia 


20 


AN 


20 


ASCII 


Credit Card pointer 


2 


N 


1 


BCD 


Company Name 


20 


AN 


20 


ASCII 



Tabic 7: Exemplary business EF file smicture 



Preferences EF 514 preferably comprises data related to the cardholder's 
default personal preferences. In a particularly preferred embodiment, preferences 
EF 514 includes a field comprising an array of preferences as set forth in Tabic 8 
below. Preference values are preferably chosen from a list of preference lags as set 
forth in Table 39. 



Record descriplion 


Exiernul rormal 


Internal for 


'mat(byic$) 




Size 


Type 


Size 


Type 


Preferences Array 


20 


C 


20 


C 



Tabic 8: Examplary preferences EF file stnicture 



Passport EF 516 is preferably used to store cardholder passport infonnaiion. 
In a particularly preferred embodiment, passport EF 516 comprises the fields set 
forth in Table 9 below. 



Record descriptioo 


External format 


•Internal for 


niat(bytes) • 




Size 


Type 


Size 


Type 


Passport Number 


20 


AN 


20 


ASCII 


Passport Countiy ~ ISO 3 1 66 


2 


AN 


2 


ASCII 


Issuance Due 


S 


D 


4 


BCD 
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City of Issuance 


20 


AN 


20 


AN 


Expiraiion Dale 


Z 


D 


4 


BCD 



Table 9: Examplary passpon EF Hie structure 



Driver EF 516 preferably comprises cardholder driver license data. In a 
5 panicularly preferred embodiment, driver EF 5 1 8 comprising ihc fields sei forth in 
Table 10 below. 



Record dcscripiion 


external formal 


Inicrnal rorniat(b3'ics) 




Size 


Type 


Size 


Type 


Driver^s License No. 


20 


a 


20 


ASCII 


Driver's License Issuing Stme/Countiy 


2 


a 


2 


BCD 


License Expiration Date 


8 


D 


4 


ASCII 


License Type 


2 


C 


4 


BCD 



Table 10: Excmplaiy driver EF file structure 



Biometric EF 522 is used lo store biomciric data (preferably encoded) such 
as fingerprint data, retina scan data, or any other sufficiently unique indicia the 
15 cardholder's physical or behavioral characteristics. In a particularly preferred 
embodiment, biometric EF 522 comprises a single data siring as set fonh in 
Table 11 below. 



Record dcscripiion 


CxiCfMi formtl 


Internal format (bytes) 




Size 


Type 


Size 


Type 


Biometrics templue 


100 


AN 


100 


BIN 



20 Table 11 : Exemplary biometric EF file stnicture 

' • 
Authentication EF 520 preferably comprises information for static 
authentication of the cardholder ID 406 applicaUon. This data is'iinique for each 



17 



card, and is sufTicicntly complex such that countcrfeii values cannoi feasibly be 
created. This prevenis acatioo of "new" counterfeit cards (i.e.. cards with new 
authentication data), but does not prevent creation of multiple copies of the 
current card. 

In a particularly prefeired embodiment, authentication EF 520 includes 
public key certificate fields as slwwn in Table 12 below, wherein the external 
formal is identical to the internal format. Preferably, the issuer RSA key is 640 
bits long, and the CA key is 768 bits long. 



10 



IS 



20 



Record description 


Internal for 


mat(byics) 




Size 


Type 


Si2>ned Sialic Applicaiion Data 


80 


B 


Sialic Dau Authentication Tag List 


16 


B 


Issuer Public Key Cert incate 


96 


B 


Issuer Public Key Exponeni 


1 


6 


Issuer Public Key Remainder 


20 


B 



Table 12: Exemplary authentication EF 

Turning now to files under miscellaneous DF 530. preferred programs EF 
528 preferably comprises data related to the cardholder's preferences as to airline 
companies, hotels, and rental car agencies. Specifically, this EF. in a particulariy 
preferred embodiment, comprises a plurality of records (e.g., three) indicating 
prefened companies for each type of travel partner as shown in Table 13. Iht 
actual data values confom, to an arbitrary convention; that is. each airline, hotel, 
and rental car agency is assigned an arbitniy three-byte code. 



Record descriptlOB 



Eiiernal format 



Size 



Type 



Internal rorinst(byte$) 



Size 
9 



Type 
C 



25 



Preferred Airlines 



9(3x3) 



Prefened Hotels 



PitfeiiedRenuUC«ra 



18 



I'sibic 13: Exemplary programs EF 



Payment card EF 5 1 0 is preferably used to caialog information related to the 
cardholder's various payment c^irds, i.e., debit cards, charge cards, and the like. In 
a particularly preferred embodiment, payment card EF comprises card numbers and 
expiration dales for two cards as shown in Table 14. The "ISO** and "non^lSO** 
designations refer to lSO-78 13, which specifies a panicular payment card number 
format. Thus, in a preferred embodiment, either an ISO or non-ISO card number 
scheme may be used. Moreover, it will be appreciated that this data set is sufTicient 
only for "card not present" transactions, for example, transaaions taking place 
remotely where only the card number and expiration date arc required to effect a 
transaction. Data stored within payment system application 408 (described below) 
must be used to effect a ^card present'* transaction. 



Record description 


External formal 


Internal forms t(bytes) 




Size 


Type 


Size 


Type 


First Payment Card H (ISO) 


19 


N 


10 


BCD 


First Payineni Card Expiraiion E>iiic 


8 


D 


4 


BCD 


Second Paymcni Card # (non-ISO) 


20 


AN 


20 


ASCII 


Second Payment Card Expiration Date 


S 


D 


A 


BCD 



Tabic ]4: Exemplary payment card EF file structure 



Sequence EF 512 preferably includes information used to provide 
synchronization of the host and smartcard databases. In a particularly preferred 
embodiment, sequence EF 512 comprises a plurality of records comprising the field 
set forth in Table 15 below. This number is analogous to a Version** number for 
the data stored in the application. 



Record description 


External format 


Internal rorinat(bytes) 




Size 


Type 


Size 


Type 



19 



Sequence Number 


16 


AN 


16 


ASCII 



Table 15: Exemplary sequence EF file strudure 



Card number EF 526 is used lo record a unique number identifying the 
smnncard. and may also be used for key derivation (as described in further detail 
below). Preferably, card number EF 526 comprises a eight-byte string as set 
forth in Table J6 below. 



RcconI descripiion 


external format 


Internal for 


'inac(byies) 




Size 


Type 


Size 


Type 


Card Number 


S 


HEX 


8 


HEX 



Tabic 16: Exeroplaiy card number EF 



1 0 Issuance EF 5 1 1 is used to record various details related to the manner in 

which the application (i.e., cardholder ID DF 406) was created. This file includes 
information related lo the identity of the orgaa-zation that created the 
application, as well as information related to the application itself. In a 
particularly preferred embodiment, issuance EF 51 1 comprises fields as set forth 

15 in Table 17 below. 
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Field 


External format 


Internal fo 


rniat (bytes) 




Size 


Type 


Size 


Type 


Counny Authority 




ISO 3 166 


2 




Issuer Authority 


10 


R]D-ISO 
7816-5 


5 


HEX 


AppKcation version 


5 


XX.YY 


2 


BCD 


Application expiration dfte 


8 


YYYYMM 
DD 


4 


BCD 


Application effective date 


8 


YYYYMM 
DD 


4 


BCD 



20 



PersonaltzerCode 


1 


AN 


1 


ASCII 


Personaliuiion Location 


I 


AN 


i 


ASCII 



Table 17: Exemplary issuance £F file structure 
The personalizercode field shown in T^ble 17 refers to the organization 
that actually "personalizes" the file. That is, before a smartcard nuiy be issued to 
the cardholder^ the database structure must be created witMn EEPROM 212 
(Figure 2), and the initial data values (i.e., default preferences, cardholder name, 
pin numbers, etc.) must be placed in the appropriate fields within the various 
EFs. It will be appreciated that, given the nature of the present invention, the 
smartcard "issuer" and "pcrsonalizer" for any given application may not be the 
same. Tlierefore^ it is advantageous to record various details of the 
personalization process within smancard 1 00 itself Similar issuance file 
structures may be provided for the other major applications. 

Payment System Application 

Referring now to Figure 6, payment system application 408 preferably 
comprises a directory EF 61 0, issuer DF 602, and a number of optional DFs 603(a)- 
(n) for use by pannering financial organizations. 

Directory EF 610 preferably includes a list of application identifiers and 
labels as described above in the context of cardholder ID application 406. 

Issuer DF 602 comprises pay] DF 604, which includes data that v^ould 
traditionally be stored within tracks on a magnetic stripe card (.i.e.. debit cards, 
charge cards, and the like). In a preferred exemplary embodiment, payl DF 604 
comprises a plurality of records having commonly known magnetic*stripe fields as 
specified in Table 1 8 below. 



Record descriplion 


External formal 


Internal rorniat<bxtcs) 




Size 


Type 


Size 


Type 


Fonnai Code (Track 1 } 


1 


AN 


1 


ASCII 
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PAN ( Track 2 ; 




N 


8 


BCDF 

right 

padding 


ExpiTBl'On OBic \ I racK i or ^ ; 


4 


YYMM 


2 


BCD 


EfTcdivc dale ( Track 1 or 2 ) 


A 


VYMM 


2 


BCD 


Discrciionary data ( Track 1 or*2 ) 


5 


N 


3 


BCDF 

right 

padding 


Name ( Track 1 ) 


26 


AN 


26 


ASCJ). U 

blank 

padding 



Tabic I«: Exemplary Pay I EF file smicturc 



Airline Application 

.Referring now lo Figure 7, airline application 410 preferably comprises 
directory EF 730, common DP 702, and issuer DF 704, and additional airiine 
1 0 applications 703(a), 703(b), and so on. 

Directory EF 730 preferably includes a list of application identifiers and 
labels as described above in the context of cardholder 1 D application 406. 

Common DF 702 generally includes data accessible to all participating 
airlines, while issuer DF 704 generally includes data which can only be read or 
15 written to by the smancard issuer. Airline application 410 preferably further 
comprises at least one (preferably three) additional DF 703 for use. by airiine 
partnering organizations. That is, one airiine partner may have access lo and specify 
the structure of dau stored within DF 703(a) (as well as common EF 702). while 
another airline might have similar access to DF 703(b). These partner DFs 
20 preferably conform to the relevant portions of the lATA specification. 

Common DF 702 suitably comprises common data which would be of use to 
any of the various partnering airiines. i.e., passenger EF 706, frequent flier EF 708, 
lET EF 710, boarding EF 712, and biometric EF 714. 
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Issuer DF 704, in conirasi, comprises information readable by all, but 
updatabic only by the card issuer, i.e., preferences EF 716, PIN EF 718, and 
issuance EF 720, 

Referring now lo information stored within common EF 702, passenger EF 
706 preferably comprises various records related to the passenger as specified in 
Tabic 19 below. 



Record description 


Cxicrnai format 


Internal format (bytes) 




Size 


Type 


Size 


Type 












Passenger Name 


49 


AN 


49 


ASCII 


Gender 


1 


A 


1 


BIN 


Language Preference 


2 


AN 


2 


ASCII 


Unique ID 


24 


AN 


24 


ASCII 


Airline ID (3 lettm code) 


3 


AN 


2 


ASCII 


Type code ( 2 teaers } 


2 


AN 


2 


ASCII 


Unique ID 


19 


AN 


19 


Asai 


Application version 


2 


N 


2 


BIN 



Tabic 19: Exemplary passenger EF file structure 



In a particularly preferred embodiment, frequent flyer EF 708 comprises a . 
plurality of frequent flier numbers (e.g... ten numbers) liaving the stnicture specified 
in Tabic 20 below. 



Record description 


External format 


Internal format (bytes) 




Size 


Type 


Size 


Type 


Airline Customer ID 


22 


AN 


22 


ASCII 



Table 20: Exemplary frequent flyer EF file structure 
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IFF EF 71 0 prefcRibly comprises a plurality of clearonic ticket records as set 
forth in Table 21 below. The format of these electronic tickets preferably conforms 
to the IATA standard. 



Dcscnpiion of ilic records 


External format 


Intcrniil format (bytes) 




Size 


Type 


Size 


Type 


lETJ 


14 


AN 




BIN 


IET2 


14 


AN 




BIN 


IET3 


14 


AN 




BIN 


IET4 


14 


AN 




BIN 


IET5 


14 


AN 




BIN 



T:iblc 21: Excmplai^ lET file structure 



In a particularly preferred embodiment, boarding EF 712 comprises boarding 
data to be used during check in as specified in Table 22. The format of this data 
preferably conforms to the IATA specification. 



Record description 


Estertiai format 


internal format (bytes) 




Size 


Type 


Size 


Type 


Boarding data 


40 


AN 


40 


ASCII 



Tabic 22: Exemplary boarding EF file structure 



Biomeuic EF 714 is suitably used to store biomeuic data associated with the 
cardholder, e.g., retina scan data, fingerprint data, or any other sufTicienily unique 
indicia of the cardholder's physical or behavioral characteristics. In a paiticularly 
preferred embodiment, biometric EF 714 comprises dau as specified in Table 23 
below. 



Record description 


Eitcmal formal 


Inicmal formal (byics) 




Size 


Typ« 


Ste 


Type 



24 



Oiomeirics dain 


100 


AN 


100 


BIN 



T»blc23: Exemplary biomctric EF file structure 



Issuance EF 720 is suimbly used to hold data related to the issuance of the 
various applications. Jn a particularly preferred embodiment, issuance EF 720 
comprises a data structure as specified in Table 24 below. 



Fldd 


External rormnf 


Internal format (bytes) 




Size 


Type 


Size 


Type 


Couniry Auihoriiy ( 2 leucrs ) 




ISO 3166 


2 




Issuer Authority 


10 


RID -ISO 


5 


HEX 






7816-5 






Appiicaifton versm 


5 


XX.YY 


2 


BCD 


AppHcaiJon expitation date 


S 


YYYYMM 


.4 


BCD 






DD 






Appiicsiion effective date 


8 


YYYYMM 


4 


BCD 






DD 






PersonstizerCode 


1 


AW 


1 


ASCII 


Personalization Location (custom code) 


1 


AN 


1 


ASCII 



Table 24: Exemplary issuance EF file stnicture 



PIN EF 718 is suitably used to store PIN valuies coiresponding to each of the 
panicipating airline partners. In a particularly preferred embodiment, PIN EF 71 8 
comprises a plurality of records having the structure specified in Table 25 below, 
wherein each record is related to the corresponding critiy in frequent flyer EF 708 
(i.c., record one in EF 71 8 corresponds to record one in EF 708, and so on.) 



Record description 


External formal 


Internal formal (bylca) 




Sne 


Type •• ■ 


Size 


Type 


PIN 


S 


AN 


8 


BIN 


Expiration date 


8 


D 


4 


BCD 
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Tabic 25: ExempUiy PIN EF file structure 



Preferences EF 716, in a particularly preferred embodiment, comprises a 
preferences array as shown in Table 26 below. The preference values stored in this 
file correspond to those discussed below in conjunction with Tabic 38. 



Record description 


External formal 


Internal format (byta) 




Size 


Type 


Size 


Type 


Preferences Array 


8 


C 


S 


BIN 



Table 26: Exemplaiy preferences EF 716 file struaure 

Rental Car Application 

Referring now to Figure 8, rental car application 414 preferably comprises 
10 common DF 802, directoiy EF 820. and one or more renial_car DFs 803 (ic 
803(a), 803(b), and so on) corresponding to individual rental car agencies. 

Common DF comprises preferences EF 805, which is described in detail 
below. Rcntal_car DFs 803 each comprise a rental_carjd EF 807, reservation EF 
809, and expenses EF 8 1 1 . 
1 5 Directory EF 820 includes a list of application identifiers and labels for the 

various DFs under reniaLcar application 414. The structure of this EF preferably 
confomis to that described above in the context of cardholder ID application 406. 

In a particularly Rrefeired embodiment, preferences EF 805 comprises a set 
of preferences ana^ file structure as shown in Table 27 below, A prefeired list of 
20 preference codes for use in each of theie arrays is described below in conjunction 
withTable38. 
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RcconI description 


External format 


Internal for 


mat( bytes) 


Preferences Anay (Default) 


t 


C 


8 


BIN 


Prefetcnees Array (No. 2) 


t 


c 


8 


BIN 


Prefocnces Array (No. 3) 


t 


c 


8 


BIN 


Prefcncd limousine company 


12 


AN 


12 


ASai 


Table27:] 


Exemplary preferaices EF 
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RcniaJ_car_id S07 is used lo store frequeni rental information, upgrade 
information, insurance inlbm^ation, and the like. In a particularly preferred 
embodiment, rental^car^id S07 comprises a file structure as shown in Table 28 
below. 



Record description 


external format 


Internal format( bytes) 


Frequent Rental IJM 


22 


A 


22 


ASCII 


Compartyfiame 


J 


A 


i 


ASCII 


Unique Customer JD 


19 


A 


19 


ASai 


CD? (Contraa Disc Program) 
— 


10 


A 


10 


ASCII 


Accunnulaied points 


Z 


N 


3 


BIN 


Reniii fcaiurcs 




AR 


2 


BIN 


Car Type Upgrade 




B 


Ibit 


B 


Wetk'-end/Vocotion Special 




B 


Ibii 


B 


Cuarameed Late Reservation 




B 


Ibit 


B 


insurance 




Amy 


2 


BIN 


Loss Damage Waiver (LDW) 




B 


1 bii 


B 


Personai Automobile Insurance 




B 


Ibit 


B 


Personal Effects Cmvrage 




B 


Ibit 


B 


Personai Insurance 




B 


Ibit 


B 


Corporate Insurance 




B 


Ibit 


B 



Tabic 28: Exemplary rcnlal^car^id EF 



Reservation EF 809 is used lo store confinnaiion numbers conesponding to 
one or more rcntaj car reservations. In a particularly preferred embodiment, 
reservation EF 809 comprises a plurality of records (c.g., two) having a file 
structure as shown in Table 29 below. 



Record description 


External formaC 


internal format( bytes) 


Rental Car Company 


3 


A 


3 


Asai 
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Location 


3 


A 


3 


ASCII 


Date 


S 


D 


4 


BCD 


Tlm< 


A 


T 


2 


BCD 


Reservation Number 


15 


A 


15 


ASCII 


night Number 




M 


5 


BIN 


Airlines 




^A' 


i 


aSCIKRJ) 


Flighi nvmber 




N 


7 


BCD 


Preferred profile 




C 


1 


ASCII 



Tabic 29: Exemplary reservaiion EF 



Expenses EF 8 M is used w rccoid expenses incunrcd by the cardholder during 
car rental (e.g., ihc total rental charge). In n paniculariy preferred embodiment, 
expenses EF 8 II comprises a plurality of records (e.g., five) having a file structure 
as shown in T«blc 30 belov*^. 



15 



Record description 


Estemal format 


Internal for 


mat( bytes) 


Type of expense 


1 


C 


1 


ASCII 


Date 


S 


D 


4 


BCD . 


Location code 


3 


AN 


3 


ASCII 


Amount 


7 


N 


3 


BIN 



Table 30: Exemplary expenses EF 

20 

Hotel Application 

Referring nowrto rigur«9.hoiel system application 4 12 preferably comprises 
directory EF 920, common DF 9M, one or more hotel chain DFs 902, and one or 
mote property DFs 903. 
25 common DF 914 comprises reservation EF 918. expenses EF 916, key-of- 

tbe-room EF 910, and preferences EF 912. 
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Hotel chain EFs 902(a), 902(b). and so on, comprise preferences EF 904 and 
stayer ID EF 906 associated with individual hotel chains. In contrast, property EFs 
903(a), 903(b), and so on, comprise a similar Tile structure associated with 
individual hoiel properties (i.e., independent of whether the particular hotel is a 
member of a nationwide chain). 

In a panicularly preferred embodiment, reservation EF 918 comprises a 
plurality of records having the stniciure shown in Table 31 below. In general, this 
EF is used to store confirmation numbers transmitted to smancard 100 when (he 
cardholder makes a reservation at a given hotel (designated in the properly code 
field). The date field stores the date on which the confirmation number was 
dispensed. 



Record dcscripiion 


£xicrnal rormvf 


Internal formai(byies) 




Size 


Type 


Size 


Type 


Property Code 


3 


AN 


3 


ASCII 


Date 


S 


D 


4 


BCD 


ConfimiiRtion Number 


13 . 


AN 


15 


ASCII 



Tabic 31 : Exemplary reservation EF 



Preferences EF 912 preferably comprises three sets of array preferences. The 
particular codes used in these arrays are discussed below in conjunction with Table 
38. 



Record description 


External format 


Internal format(byia) 




Size 


Type 


Size 


Type 


Preferences Array (defsuh) 


8 


C 


8 


BIN 


Preferences Array (number 2) 


8 


C 


8 


BIN 


Preferences Amy (number 3) 


t 


C 


8 


BIN 



Table 32: Exemplary preferences EF 
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Expenses EF 9J6 preferably comprises a list of rccem hotel expenses, for 
example, room costs, dinner expenses, and the like. In a particuJarly preferred 
embodiment, expenses £F 916 comprises a plurality of records (for example, 
fifteen) arranged in a cyclic file structure and comprising the fields sho>vn in Table 
33 below. Thus, the cardholder is able to examine and print a list of recently 
incurred expenses by type (a code fixed by convention), date, amount, and property 
ccklc. 



Record description 


Cxiemal fc 


urinal 


internal for 


-Riat(b3rtes) 




Size 


Type 


Size 


Type 


Type 


f 


c 


1 


ASCII 


Dare 


8 


D 


A 


BCD 


PropenyCode 


3 


AN 


3 


ASCII 


Amount 


7 


N 


3 


BIN 



Tabic 33: Exemplary expenses EF 



Key-of-the-room EF 910 preferably comprises electronic key values that can 
be used in conjunction vdth card readers to pro^ndc access to particular hotel rooms. 
In a particularly preferred embodiment, key-of-thc-room EF 910 comprises a 
plurality of alphanumeric key values as shown in Tabic 34 below. 



Record description 


External formal 


Internal for 


inat(byics) 




Size 


Type 


She 


Type 


K«y value 


40 


AN 


40 


BIN 



Table 34: Exemplary kcy-of-the-room EF 



Stayer ID EF 906 prefeiably comprises frequent stayer data for a particular 
hotel chain. In a particularly ptefened embodiment. Stayer ID EF 906 comprises 
frequent stayer information as shown in Table 35 bdow. 
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Rccgrd description 


External formnf 


Internal 

rormat(byte$) 




Size 


Tvoc 


Size 


Type 


Frequent stdyer number 


19 


AN 


19 


ASCII 


j*rCQUcni i^Mijrw ii^Yd ^iwc- 


1 


AN 


1 


ASCII 


Frequent Stayer Level Expimion Date 


6 


YYYYMM 


3 


BCD 


CDP 


10 


AN 


10 


ASCII 


Event Counter 




N 


I 


BIN 


Hotel Frequent Stayer PIN 


8 1 


AN 


8 


BIN 



Tabic 35: Exemplary stayer ID EF 



Preferences EF 904 preferably comprises three sets of array preferences as 
sho^vn in Tabic 36. The particular codes used in these arrays are discussed below 
in conjunction with Table 38. 



Record description 


External format 


Internal rormat(byics) 




Size 


Type 


Sac 


Type 


Preferences Array (dcfaull) 


8 


C 


8 


BIN 


Preferences Array (number 2) 


8 


C 


8 


DIN 


Preferences Array (number 3) 


8 


C 


8 


BIN 



Table 36: Exemplary preferences EF 



Property DFs 903(aX 903(bX etc., arc used in cases where the partnering hotel • 
is not part of a major chain, or ^en the hotel chooses to employ its own data set 
independent of its affiliation. In one embodiment, these property DFs arc identical 
in structure to hotel chain DFs 902, except that much of the frequent stayer ID 
information is removed. More specifically, a typical property DF 903 comprises a 
preferences EF 938 identical to preferences 904 described above, along with a 
stayer ID EF 934 which includes only the CDP, event counter, and hotel frequent 
suyer PIN fields described in conjunction with Table 33 above. Alternatively, a 
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particular hotel chain or property mighi choose to implement a 
structure than that described above. 
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Preference Codes 

AS mentioned briefly above, a prtfcn^d embodiment is configured such «hat 
preferences are located in several files distributed throughout smartcard 100; i:c.. 
in preferences EF 514, airline preferences EF 716. hotel preferences EF 912 and 
904. and car preferences EF 8 1 0. This alloxvs apparently conflicung preferences to 
coeilist vnthin the card depending on context. For example, il is possible to opt for 
non-smoking in the cardholder ID application while choosing the smoking option 
within the hotel application. In the case of conflict, preferences are read from the 
top level to the bottom level, and each level supersedes the previous one. 

An exemplary set of codiHcation n.les are set forth iii Tabic 37 below. 



IS 



0-49 General purpose (Cardholder ID 406) 

50-99 Hotel application 412 

1 00- 1 49 Ren«' application 4 1 4 

150-199 Airline application 410 

200-255 Other 
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Table 37: Exemplary Preferences Code Ranges 

More specifically, in a prefened exemplary embodiment, pnrference Dags a,e 
coded as set forth in Table 38 below. 
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Code (decimaO 


GENERAL PURPOSE 




Smoking - 


00 


NofHsmoking^ - 


01 


Home as prefened address 


02 


Work as preferred address 


03 


Handicapped . 


04 
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Home as preferred e-mail address 


05 


Work as preferred e-mail address 


06 






HOTEL PREFERENCES 




Kin^'Size bed 


50 


Queen-size bed 


51 


Double bed 


52 


Hifh floor room 


53 


Low floor room 


54 


Near elevator room 


55 


A^^y from elevator room 


56 






RENTAL CAR PREFERENCES 




Compact car 


100 


Standard car 


101 


Mid-size car 


102 


Luxury car 


103 






AIRLINE PREFERENCES 




Window seat preferred 


150 


Aisle seal preferred 


151 


Low calorie 


152 


Ve^eiarian 


153 


Diabetic 


154 


Low sodium 


155 


Kosher 


156 



Table 38: Exemplary preference codes 



Security 

.In the context of smancard transactions, data security has five primary 
dimensions: 1} data confidentiality, 2} data integrir/, 3) access control, 4) 
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amhcnt icaiion. and 5) non-repiidiaiion. Each of these dimensions is addressed 
through a variety of security mechanisms. Data confidentiality, which deals with 
keeping information secret (i.e, unreadable to those without access to a key), is 
substantially ensured using encTj-ption technology. Data integrity (and data source 
5 verification) focuses on ensuring that data remains unchang^ during transfer, and 
typically employs message authentication techniques. Access control involves card 
holder verification and other requirements necessary in order for a party to read or 
update a particular file. Authentication involves ensuring that the card and/or the 
external device is what it purports to be, and non-repudiation deals with the related 

10 task of ensuring that the source of the data or message is authentic, i.e., that a 
consumer may not repudiate a transaction by claiming that it was "signed" by an 
unauthorized party. 

Authentication is preferably pcrfomied using a "challenge/re^nsc" 
algorithm. In general, authentication through a chaJlenge/response system involves: 

15 I) generation of a random number by a first party; 2) transmission of the random 
number to a second party (the "challengers) encryption of the lahdom number by 
the second party in accordance with a key known to both parties, 4) transmission 
of the encrypted random number to the first party (the "response'^. 5) encryption 
of the random number by the fust pany, and 6) comparison by the first party of the 

20 two resulting numbers. In the case where the two numbers match, authentication is 
successful; if not. the authcmication is unsuccessful. Note that authentication can 
work both ways: the external worid might request authentication of a smartcard 
(internal authentication), and a smancard might request auihemication of the 
external world (external authentication), a more deuiled accoum of a preferred 

25 challcngeAesponsc algoritian can be found in the IBM MFC specification. 

In a preferred embodiment, ti« DES algoritiun (Data Encryption Standard) 
is employed for the various security functions; however, it will be appreciated that 
any number of other symmetrical or asymmetrical techniques may be used in the 
context of tiic present invention. More particulariy, there are two general categories 

30 of encryption algorithms: symmetric and asymmetric. Synunetric algorithms use the 
same key for encryption and decryption, for example, DEA (data enayption 
algorithm) which uses a 56-bit key to encrypt 64-bit blocks of data. Asyininciik 
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algorithms, in comrasi, use xwo different ktys: one secret key and one public key. 
The RS A algorithm, for example, uses two such keys and exploits the 
computational complexity of factoring very large prime numbers. Additional 
information these aiid other cryptographic principles can be found in a number of 
standard texts, for example: Scbcrry & Picprzyk, CRYPTOGRAPHY: AN 
Introduction to Computer Security (1989); Rhcc, Cryptography and 
Secure Communications (1994); Siinson» Cryptography: Theory and 
Practice ( 1 995); Contemporary Cryptography: The Science of Information 
Integrity (1992); and Schncicr, APPLIED Cryptography (2d cd. 1996)» the 
contents of which are hereby incorporated by reference. 

Access control is suitably provided by including access conditions within the 
header of each EF and DP. This prevents a particular operation (e.g., reading or 
updating) from being performed on a file unless the required access conditions have 
been fulfilled. Many different access conditions are appropriate in a smart card 
context. For example, the smartcard might require cardholder verification (i.e., 
request that the cardholder enter a PIN) before a flle operation is allowed. Similarly, 
internal and/or external authentication as described above might be required. 

Another important access condition (referred to herein as the SIGN condition) 
corresponds to the case where a particular file is "protected" and where updating of 
a record requires **signing" of the data using a message authentication code (MAC), 
a MAC can be thought of as a form of electronic sea] used to authenticate the 
contem of the message. In a paradigmatic signing procedure, a shortened, encrypted 
representation of the message (the MAC) is created using t message authentication 
algorithm (MAA) in conjunction with a key known to both the card and external ' 
device. The MAC is then appended onto the message and sent to the card (or 
external device, depending on context), and the card itself generates a MAC based 
on the received message and the known key. The card then compares the received 
MAC with the its own iniemally-gencraied MAC. If either the message or MAC 
was altered during transmission, or the sending party did not use the correct key, 
then the two MACs will not match, and the access condition will not be fulfilled. 
]f the two MACs correspond, then the access condition is fulfilled, and the 
particular file operation can proceed. 
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A MAC may be generaied using a variety of MA As, for example, the ANSI 
X9.9 method using an cighi-byic key, or the ANSI X9. J 9 method using a sixteen- 
byte key. Funhcmiore, the actual key may be "diversified" through cncrj-ption with 
a random, number or other appropriate value. These and other details regarding 
5 MAC generation can be found in the references cited above as well as the IBM 
MFC specification. 

Two other important access conditions are the NEVER and FREE conditions. 
The NEVER condition conesponds to the case where a certain file operation 
(typically updating) is never altowed. The FREE condition, on the other hand, 

J 0 corresponds to the case where either updaUng or reading a file record is always 
allowed, without any additional preconditions for access. 

In contrast to the MAC techniques discussed briefly above, non-repudiation 
is necessarily performed using asymmeirlcal techniques. That is, as symmetrical 
techniques such as MAC "scaling" use a key known to more than one party, such 

1 5 techniques can not be used by a third pany to ascertain whether the source of the 
message is correct. Thus, non-repudiation typically employs a public key encryption 
scheme (e.g, the Zimmerman's PGP system), wherein the sender uses a secret key 
to "sign" the message, and the receiving party uses the corresponding public key to 
authenticate the signature. In the context of the present invention, this function is 

20 suitably performed by allocating an EF for public and secret key rings, which are 
well knovm in the art. along with suitable encryption software resident in the card 
for assembling the signed message. 

Having thus given a brief overview of typical smaitcard security procedures, 
an exemplary set of access conditions is set forth below in Table 40. In this regard. 

25 the various access conditions for each EF are tabulated with regard to whether the 
file is being read or updated. In each case, the access condition (FREE, SIGN, etc.), 
key "owner" (issuer, partner, user. etc.). and key name are listed. In this regard, it 
wiU be appreciated that the key name is arbitrary, and is listed here for the sake of 
completeness. 
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READING 




UPDATING 






Access 
condliion 


Owner 


Key 


Access 
condition 


OvMicr 


Key 




MF 
















DF Cardholder ID 406 
















DFHoldcrJD502 
















EFID504 


FREE 




• 


«9iun 




WPVI 


5 


EF Home 506 


FREE 








icci ten 


If nvi 




EF Busbies 508 


FREE 










V CVI 
RCTI 




EF Preferences 514 


FREE 






SIGN 


-ICCI ICD 

ISSUcK 


KEYI 




£FPisspon5l6 


FREE 






SIGN 


ISSUER 


KEYl 




EFDionieirtcs522 


FREE 






SIGN 


ISSUER 


KEYI 


10 


EF Driver 5lil 


FREE 






SIGN 


ISSUER 


KEYl 




DFMisccllsneous 
















EFPvymcni card 510 


FREE 






SIGN 


ISSUER 


KEYI 




EF Sequence 5 13 


FREE 






FREE 








EF Card Number 536 


FREE 






SIGN 


ISSUER 


KEYl 


15 


DF Payment Syflem 408 
















DF Issuer 602 
















EF Pay I 604 


FREE 






FREE 









DF Airline 4 10 
















DF Common 702 
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EF PMScnfcr706 


FREE 






SIGN 


ISSUER 


KEY2 




EF Frequcni flier 708 


iniEE 






SIGN 


ISSUcR 




• 


. EFiET7IO 


FREE 














EF Boarding 712 


FREE 






rKcJi 








EFBiomemc7l4 


FREE 






rKbC 






25 


DFlswer704 






• 










EF Preferences 716 


FREE 






SIGN 


tcci ten 






EF PIN 718 


FREE 














EF Issuince 720 


FREE 






SIGN 


ISSUER 


KEY2 




DF Rental car 4 14 
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DF Common 802 
















EF References 805 


FREE 






USER 


IDEKT 


PIN 




DFRcntal^car803 
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SIGN 



FREE 

SIGN 
(append) 
IDENT 
(erase) 



RENTCAR 



RENTCAR 
(sippcnd) 
USER 

(erase) 



KEY6 



KEY6 

(append) 

PIN 

(cmc) 



FREE 



FREE 
(append) 
IDEKT 
(erase) 

FREE 

SIGN 

SIGN 



USER 
Icrase) 



ISSUER 



ISSUER 



SIGN 



HOTEL 



PIN 
(erase) 



KEYS 



liF RcniaLw.lD«07 



£F Rcsenraiicm 809 
EF Expenses 81 1 



OF Hotel s ystcm4l2 
OF Common 9 M 



BF Reservation 918 



CF Expenses 916 



EF Ke>'-oMhe-room 910 
EF Prcrerences.912 
DF H otetchain 902 
EF Preferences 904 



EF Stayer ID 906 



FREE 



FREE 
FREE 



FREE 



FREE 



FREE 
FREE 

FREE 



FREE 



Tabic 40: Exemplary access conditions 
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Transactions 

Having ihus given a deiailed description of an exemplary smancard 100 and 
a preferred dau smK:ture 400. the various details related to transactions involving 
smartcard 100 will now be described. In general, a typical smaitcard session 
Involves: (1) activation of the contacts (or comparable non^ntact means); (2) card 
reset; (3) Ans>ver to reset (ATK) by card; (4) Information exchange between card 
and liost; and. at the conclusion of a session, (5) deactivation of cont««. 

First, card 1 00 is inserted in a card reader provided at an access point IS.and 
suiuibleconnections are made betv^ communication region 104oncard 100 and . 
^ card reader. In a preferred embodiment, physical contacts (contacts 106 m 
Figure 1) aie used, and DATA. CLOCK. RESET. VDD. and GND connections are 
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made. ITiese contacts are electrically activated in a particular sequence, preferably 
in accordance with ISO 78)6-3 (RST to low state, VDD powered, DATA to 
reception mode, then CLK applied). 

The card reader then initiates a reset (i.e., RST to high state), and the card 
returns an answer lo reset string (ATR) on the DATA line, preferably in 
conformance with the content and liming details specified in the appropriate pans 
of ISO 7816. In a preferred embodiment, the interface characters are chosen to 
reflect a T^l protocol (asynchronous, half-duplex, block-oriented mode). Further 
in accordance with lSO-781 6-3, after the card sends an ATR string and the proper 
protocol is selected (in a preferred embodiment, the T«l mode), host 314 and card 
100 begin the exchange of commands and responses that comprise a particular 
transaction. The nature of these commands is discussed in further detail below. 

At the end of a smancard session, contacts 106 are deactivated. Deactivation 
of contacts 1 06 is preferably performed in the order specified in ISO 781 6-3 (i.e., 
RST to low state, CLK to low state, DATA to low state, VDD to inactive state). As 
mentioned above, the VPP contact is not utilized in a preferred embodiment. 

In the context of the present invention, command classes and instructions are 
provided for 1 ) working with application data (i.e., files stored within the various 
applications), 2) ensuring data security, 3) card management, and 4) performing 
miscellaneous functions. 

Application data commands are suitably directed at selecting, reading, and 
updating individual records or groups of records within files. Security commands 
suitably include commands for perfomiing ihe challenge/response authentication 
process, generating random numbers, loading or updating cryptographic keys, and 
changing and verifying the card-holder verification codes (CHVI and CHV2). Card 
management commands suitably include commands vs^ch allow for the creation 
and deletion of directories (DFs) and elementaiy files (EFs). Miscellaneous 
commands are suitably provided for modifying the baud rate and reading various 
card statistics (e.g., data logged during production of the card.) It will be 
appreciated that many different command sets could be designed for implementing 
these basic functions. One such command set is provided by the IBM Multifunction 
Card Operating System 3,5 1 , hereby incorporated by reference. 

39 



Referring again lo Figure lO, access poini 1 5 preferably comprises software 
which provides a user inierfacc (for example, a graiAical user interface) and is 
capable of executing the appropriate SCOS commands in accordance with the 
particular transaction being effected. For example, conadcr the case where a 
cardholder wishes to add a preference in car preferences EF 810 within rental car 
application 414 (shown in Figure 8). In this instance, a cardholder would locate a 
convenient access point 15 (for example, a stand-alone kiosk in a mall) and insert 
card 100 in a provided card reader in order to inhiate a transaction. After suitable 
handshaking between can! 100 and the card reader has taken place, and after the 
cardholder has been properly authenticated (i.e., the correct access conditions for 
updating car" preferences EF 810 have been fulfilled), the application program at 
access point 15 queries the user with a choice of preference codes (for example, 
those listed in Tabic 39 above). The user then indicates a choice - through texnjal 
or graphical means, and the appropriate value is sent to card 1 00 by the application 
program as pan of a command string. This value may then be sent to the appropriate 
partnering organization 12 (i.e., a rental car partner) and issuer 10 over network 19 
to be stored in their respective databases 13 and 1 1. Ahematively. this data may be 
sent later as part of a card/database synchronization procedure, e.g., when the 
original transaction proceeds ofT-line. 

Consider, as another example, the typical hotel transaction. As detailed above, 
the cardholder inseru cani 100 into a card reader deployed at a suitable access poim 
15. After appropriate initialization procedures take place, the cardholder is 
presented, through the use of a graphical user interface, the option to make a hotel 
reservation. Upon choosing this option, the software may interrogate the hotel 
preferences field in prefened programs EF 524 in cardholder ID application 406 and 
display these hotels first witMn the list of possible dwices. 

After the cardholder selects a specific hotel property, the software contacts the 
appropriate partner 12 over nctworic 19 and requests a hotel room for a particular 
set of dates. This step might involvfe ah interrogation of the various files within 
hotd system application 412 to which the particular hotel has access (i.e., a hotel 
chain-DF 902 or property DF 903). or this step may be deferred until cbeck-in (as 
descnlxd below). 
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Once a reservation has been made, ihe associated confiimation number 
supplied by the hotel is downloaded into the confinnation number field in 
reservation £F 91 8 along with the date and the property code of the hotel. This step 
might require the cardholder to transmit appropriate credit card information, which 
is suitably retrieved from pay I EF 604, 

Upon arrival at the hotel, the cardholder may use smartcard 1 00 to access a 
kiosk or other convenient access point provided for check-in. Thus, check-in may 
take place unassisted by hotel personnel, or may involve a more traditional person- 
to-person interaction where card 100 is used primarily to streamline the check-in 
process initiated by personnel at the front desk. 

At check-in, the confirmation number infomiation is retrieved from 
reservation EF 918., and a particular room is assigned (if not assigned previously). 
This step will typically involve retrieving, from the appropriate preference file (i.e., 
preferences EF 904 or 912X a list of preferences regarding bed size, room type, and 
the like. This list may be matched against the hotePs database of available rooms, 
thereby helping to streamline the room assignment process. • 

Once a room is assigned^ a digital key corresponding to the assigned room 
(e.g,, a numeric value or alphanumeric string) may be stored in key-of-the-room EF 
910. Card readers are then employed as pan of the door lock apparatus for each 
room, which are configured to open only upon receiving the conect key. 

At check-out time, payment may take place using payment card information 
stored in payment card EF 5 1 0 and pay I EF 604. Again, a suitable smartcard reader 
(i.e.» an access point 15), may be provided in any location convenient for check out, 
e.g., the hotel lobby or within the individual hotel rooms themselves. The 
cardholder may then acquire frequent stayer points, which would involve updating 
one of the stayer ID EFs 906 (or 936). During the course of his stay at the hotel, the 
cardholder may have incurred any number of expenses related to room-service, on- 
site dining, film viewing, and the like. These expenses, or a subset thereof, may be 
conveniently downloaded into expenses EF ,916 for later reuieval, printout, or 
archiving. 

Use of card 100 in a rental car context would necessarily involve many of the 
same steps described above. The task of assigning a car would involve retrieving 
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car preferences stored within preferences EF 805 and comparing them lo a database 
of available auiomobiles. Upon reiuruing the automobile, the cardholder might then 
be awarded frequent rental points (through update of frequent renter EF 807). and 
an expense record might be stored within expenses EF 81 J . 

In the airline context, card 1 00 could be used to make reservations, record, 
preferences, and provide a payment means as described above. In addition, 
electronic tickets may be downloaded (EF lET 710). and boarding infonnation may 
be.supplied via boarding EF 712. Frequent flyer EF 708 may then be used to update 
Ihe cardholder's frequent flyer miles. 

While the example transactions set forth above are described in general terms, 
the particular nature of data flow to and from the appropriate memory locations 
within the card will be apparent to those i'tilled in the an. 

Moreover, although the inventions set forth herein have been described in 
conjunction with the appended drawing figures, those skilled in the art will 
1 5 appreciate that the scope of the invention is not so limited. For example, although 
the preferred embodiment of the invention is discussed in the context of a standard, 
credit card-sized smartcard with external corjtacts. it will be appreciated that 
virtually any portable memory device suitably configured may be utilized to 
practice this invention, for example, contaaless cards, optical cards, minicards. 
20 "super-smart" cards, and the like. Hence, various modifications in the design and 
arrangement of the componems and steps discussed herein may be made without 
departing from the scope of the invention as set forth in the appended claims. 
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CLAIMS: 
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1. A smartcard apparatus of the type configured to communicate with an external 
device to perform a transaction, said smartcard apparatus comprising: 
a smartcard body; 

an integrated circuit device disposed within said smartcard body and configured 
to communicate with said external device, said integrated circuit device including a 
cardholder ID application for storing information related to a cardholder's identity, and 
a payment system application, said paymem system application including fields for 
storing indicia of at least one credit account associated with a partnering organization; 
and 

communication means for providing data communication between said 
integrated circuit device and said external device. 

2. The smartcard apparatus of claim 1 , wherein said integrated circuit device 
further comprises an airline application, said airline application including a common 
airline file and a second airline file associated with a partnering organization. 

3. The smartcard apparatus of claim 1 . wherein said integrated circuit device 
further comprises a rental car application, said rental car application including a 
common car file and a second car file associated with a partnering organization. 

4. . The smartcard apparatus of claim 2, wherein said integrated circuit device 
further comprises a hotel application, said hotel application including a common hotel 
file and a second hotel file associated with a partnering organization. 

5. A smartcanl apparatus of the type configured to communicate with an external 
device to perfonn a transaction, said smartcard apparatus comprising; 
a smartcard body; 

an integrated circuit device disposed within said smartcard body, said integrated 
circuit device comjuising: 
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(a) a cardholder identification application; 

(b) at least one second application for storing travel related information, said 
second application comprising a common file structure and at least one partner file 
structure; 

a communication means for providing data communication between said 
integrated circuit device and said external device. 

6. A smartcard apparatus in accordance with claim 5, wherein said conrniunication 
means comprises a plurality of external contacts disposed upon said smartcard body. 

7. A smartcard apparatus in accordance with claim 5, wherein said second 
application comprises: 

a payment system application; 
an airline application; 
a hotel application; or 
a rental car application. 

8. A smartcard apparatus of the type configured to conununicate with an external 
device to perfomi a transaction, said smartcard apparatus comprising: 

a smartcard body; 

an integrated circuit device disposed within said smartcard body and configured 
to communicate wiA said external device, said integrated circuit device comprising a 
common application and a second application, said second application bemg configured 
to store travel-related information associated with a cardholder, and 

communication means for providing data conrniunication between said 
integrated circuit device and said external device. 

9. The smartcard apparatus ofclaim 8, wherein said conrniunication means 
comprises a plurality of external contacts disposed on a surface of said smartcard body. 
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10. The smartcard apparatus of claim 8, wherein said second application comprises a 
payment system application. 

1 1 . The smartcard apparatus of claim 1 0, wherein said payment system application 
is configured to store an account number and an expiry date associated with a payment 
account. 

1 2. The smartcard apparatus of claim 8, wherein said second application comprises 
an airiine application. 

13. The smartcard apparatus of claim 12, wherein said airline application is 
configured to store an electronic ticket. 

14. The smartcard apparatus of claim 8 .wherein said second application comprises a 
hotel application. 

15. The smartcard apparatus of claim 14, wherein said hotel application is 
configured to store data associated with a hotel reservation. 

16. The smartcard apparatus of claim 8. wherein said second application comprises a 
rental car application. 

17. The smartcard apparatus of claim 1 6, wherein said rental car application is 
configured to store data associated with a car preference. 

1 8. The smartcard apparatus of claim 8, wherein said common application comprises 
an application configured to store indicia of said cardholder's identity. 

19. The smartcard apparatus of claim 18, wherein said indicia of said cardholder's 
identity includes a name and an address. 
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20. The smarlcard apparatus of claim 8, wherein said common application provides 
general read access. 

21 . The smartcard apparatus of claim 8, wherein said second application comprises a 
common file structure and a partner file structure, wherein said partner file structure 
provides write access to a field within said partner file structure for a first partnering 
organization and denies write access to said field for a second partnering organization, 
and said common file structure provides write access for both said first and second 
partners to at least one field in said common file structure. 

22. A distributed transaction comprising: 

a network for transmitting transaction information; 

a partnering organization having an associated partnering organization server, 
said partnering organization server being configured to send and receive said transaction 
information over said network; 

a smartcard access point, said smartcard access point being configured to 
interface with a smartcard and to accept user input, wherein said access point is fiirther 
configured to send and receive said transaction information over said network in 
response to said user input, said smartcard comprising: 

a smartcard body; 

an integrated circuit device disposed within said smartcard body and configured 
to communicate with said smartcard access point, said integrated circuit device 
comprising a common application and a second application, said second application 
being configured to store travel-related information associated with a cardholder; and 
communication means for providing data communication between said integrated circuit 
device and said smartcard access point. 
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